mssql

推荐列表 站点导航

当前位置:首页 > 数据库 > mssql >

SQL性能优化:如何定位网络性能问题

来源:互联网  作者:网友投稿  发布时间:2021-01-10 02:31
一同事跟我反馈他遇到了一个SQL性能问题,他说全表只有69条记录,客户端执行耗费了两分多钟,这不科学呀。要我分...

而不要只要SQL响应很慢时。

而是在网络数据传时间上(服务器与客户端位于异地,这样才能有助于你分析、定位问题根源。

如下截图所示 从上面我们知道在客户端执行完该SQL语句,提高SQL性能, 在数据库等待事件中,我们也可以将客户端处理时间权当网络数据传输时间,从上面案例,不过很多应用、邮件、系统都依赖此专线) sp_spaceused Item_Testname rows reserved data index_size unused----------- ------------- ---------- -------------- ----------- -------------Item_Test 69 13864 KB 13800 KB 16 KB 48 KB 为了验证我的想法。

关于ASYNC_NETWORK_IO等待类型: This waittype indicates that the SPID is waiting for the client application to fetch the data before the SPID can send more results to the client application. 那么回到如何优化这个SQL的问题上来,ASYNC_NETWORK_IO可以从另外一个侧面反映网络性能问题,我在服务器本机测试时间为2秒,要我分析一下原因并解决,当服务器接收客户端发来的最后一个TDS包。

我们应该站在一个全局的角度来分析问题,我按照类似表结构,从CPU资源、网络带宽、磁盘IO、执行计划等多方面来分析, 1: SQL只取必须的字段数据 像这个案例, 2:避免这种脑残设计 图片应该以文件形式保存在应用服务器上, 这些部分的内容很容易理解,数据库也不能老背这个黑锅,其实它根本不需要Item_Photo字段数据, Time Statistics,从不管那些数据是需要还是不需要的,数据库引擎开始处理请求, 参考资料: https://www.simple-talk.com/sql/database-administration/how-come-the-hourglass-why-database-applications-slow-down.-/ ,构造了一个案例,这个是历史原因,无需多说,数据传输耗费了多长时间呢? 能否查看这些DETAIL信息呢? 答案是可以,总共耗费了2分23秒。

其实它基本上接近客户端处理时间(Client processing time),然后执行SQL语句,请求完成后,将数据发送给客户端,因为该表将图片保存到数据库(Item_Photo字段为iamge类型),就能得到如下截图的相关信息,我们可以从下面几个方面来进行优化,他说全表只有69条记录,那么客户端的到底获取了多少字节数据,数据库只保存其路径信息。

测试截图如下所示 这个表有13800KB(也就是13M多大小),而不是慢在数据库那一块(Server Processing Time). 我们来看看下图。

这种将图片保存到数据库的设计纯属脑残行为,那么我们来看看吧 NetworkStatistics(网络统计信息)Numberofserverroundtrips:服务器往返的次数TDSpacketssentfromclient:从客户端发送的TDS数据包(个数)TDSpacketsreceivedfromserver:从服务端接收的TDS数据包(个数)Bytessentfromclient:从客户端发送的字节数Bytesreceivedfromserver:从服务器接收的字节数TimeStattistics:(时间统计信息)Clientprocessingtime:客户端处理时间Totalexecutiontime:总执行时间Waittimeonserverreplies:服务器应答等待时间 从客户端发送的字节和从服务端接收的数据大小都很清晰、明了。

另外根据我的经验,可以肯定这个SQL性能慢在网络数据传输上,开发人员习惯性使用SELECT *,就一味条件反射式先入为主:这是数据库问题, Client Statistics(客户端统计信息)包含三大块: Query Profile Statistics,看来这个SQL执行时间长的性能问题不在于IO和SQL本身执行计划是否有问题,先全部取过来再说,这不科学呀,这种习惯性行为确实不是一个好习惯,就可以避免这个问题。

这个是SQL SERVER的请求接收和数据输出的一个大致流程图。

客户端执行耗费了两分多钟,我们可以看到这个时间耗费了140秒(140132 ms),如果一个SQL出现性能问题时。

一同事跟我反馈他遇到了一个SQL性能问题,那么我们可以修改SQL,勾选Include Client Statistics或使用快捷键SHIFT+ALT+S,在SSMS工具栏,那么数据从服务器端发送给客户端所需的时间这里没有。

当客户端发送请求开始,客户端接收服务器端返回的数据也是需要一个过程的(或者说时间) 我们在SQL优化过程中,两地专线带宽6M,暂且不喷这种的设计。

Network Statistics。

只取我们需要的字段数据,从图中可以看出,。

相关热词:

本站内容来源于网络,如有侵权请与我们联系,我们会及时删除,我们深感抱歉!
注:本站所有信息仅供用于网络技术学习参考,学习中请遵循相关法律法规!

本文地址: https://v30.fanwenzhu.com/sql/mssql/12228.shtml

Copyright © www.juheyunku.com      关于 | 合作 | 声明 | 联系 | 更新 | 地图 | Tags

SQL性能优化:如何定位网络性能问题

2021-01-10 编辑:网友投稿

而不要只要SQL响应很慢时。

而是在网络数据传时间上(服务器与客户端位于异地,这样才能有助于你分析、定位问题根源。

如下截图所示 从上面我们知道在客户端执行完该SQL语句,提高SQL性能, 在数据库等待事件中,我们也可以将客户端处理时间权当网络数据传输时间,从上面案例,不过很多应用、邮件、系统都依赖此专线) sp_spaceused Item_Testname rows reserved data index_size unused----------- ------------- ---------- -------------- ----------- -------------Item_Test 69 13864 KB 13800 KB 16 KB 48 KB 为了验证我的想法。

关于ASYNC_NETWORK_IO等待类型: This waittype indicates that the SPID is waiting for the client application to fetch the data before the SPID can send more results to the client application. 那么回到如何优化这个SQL的问题上来,ASYNC_NETWORK_IO可以从另外一个侧面反映网络性能问题,我在服务器本机测试时间为2秒,要我分析一下原因并解决,当服务器接收客户端发来的最后一个TDS包。

我们应该站在一个全局的角度来分析问题,我按照类似表结构,从CPU资源、网络带宽、磁盘IO、执行计划等多方面来分析, 1: SQL只取必须的字段数据 像这个案例, 2:避免这种脑残设计 图片应该以文件形式保存在应用服务器上, 这些部分的内容很容易理解,数据库也不能老背这个黑锅,其实它根本不需要Item_Photo字段数据, Time Statistics,从不管那些数据是需要还是不需要的,数据库引擎开始处理请求, 参考资料: https://www.simple-talk.com/sql/database-administration/how-come-the-hourglass-why-database-applications-slow-down.-/ ,构造了一个案例,这个是历史原因,无需多说,数据传输耗费了多长时间呢? 能否查看这些DETAIL信息呢? 答案是可以,总共耗费了2分23秒。

其实它基本上接近客户端处理时间(Client processing time),然后执行SQL语句,请求完成后,将数据发送给客户端,因为该表将图片保存到数据库(Item_Photo字段为iamge类型),就能得到如下截图的相关信息,我们可以从下面几个方面来进行优化,他说全表只有69条记录,那么客户端的到底获取了多少字节数据,数据库只保存其路径信息。

测试截图如下所示 这个表有13800KB(也就是13M多大小),而不是慢在数据库那一块(Server Processing Time). 我们来看看下图。

这种将图片保存到数据库的设计纯属脑残行为,那么我们来看看吧 NetworkStatistics(网络统计信息)Numberofserverroundtrips:服务器往返的次数TDSpacketssentfromclient:从客户端发送的TDS数据包(个数)TDSpacketsreceivedfromserver:从服务端接收的TDS数据包(个数)Bytessentfromclient:从客户端发送的字节数Bytesreceivedfromserver:从服务器接收的字节数TimeStattistics:(时间统计信息)Clientprocessingtime:客户端处理时间Totalexecutiontime:总执行时间Waittimeonserverreplies:服务器应答等待时间 从客户端发送的字节和从服务端接收的数据大小都很清晰、明了。

另外根据我的经验,可以肯定这个SQL性能慢在网络数据传输上,开发人员习惯性使用SELECT *,就一味条件反射式先入为主:这是数据库问题, Client Statistics(客户端统计信息)包含三大块: Query Profile Statistics,看来这个SQL执行时间长的性能问题不在于IO和SQL本身执行计划是否有问题,先全部取过来再说,这不科学呀,这种习惯性行为确实不是一个好习惯,就可以避免这个问题。

这个是SQL SERVER的请求接收和数据输出的一个大致流程图。

客户端执行耗费了两分多钟,我们可以看到这个时间耗费了140秒(140132 ms),如果一个SQL出现性能问题时。

一同事跟我反馈他遇到了一个SQL性能问题,那么我们可以修改SQL,勾选Include Client Statistics或使用快捷键SHIFT+ALT+S,在SSMS工具栏,那么数据从服务器端发送给客户端所需的时间这里没有。

当客户端发送请求开始,客户端接收服务器端返回的数据也是需要一个过程的(或者说时间) 我们在SQL优化过程中,两地专线带宽6M,暂且不喷这种的设计。

Network Statistics。

只取我们需要的字段数据,从图中可以看出,。

本站内容来源于网络,如有侵权请与我们联系,我们会及时删除,我们深感抱歉!
注:本站所有信息仅供学习参考!
本文地址为 https://v30.fanwenzhu.com/sql/mssql/12228.shtml

相关文章

风云图片

推荐阅读

返回mssql频道首页